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PROOF OF INVENTION 



This docmnent shows the conception of the invention clairaed in US patent application 
09/498,505 as disclosed in the document 

[2] Developing Publish/Subscribe Applications with iBus - Technical White Paper 

Revision 1.1, A/^n May 17 i 3:58:2.^ 1999 (/TC (4 yeai-s, 10 months ago) by ,vUvcmo 

which in the following shall be referred to as ^'White Paper" 

A copy of the white paper in which the relevant sections are highlighted is enclosed. 

SYNOPSIS OF CLAIMED MATTER AND DISCLOSURE IN WHITE PAPER 

The subject matter of the independent claims 1, 8, 11, 12 is disclosed in the white paper. In 
the following, reference is made to claim 1 alone. The remaining independent claims are 
directed to a method for mnning a message system and a computer progi-am product for 
implementing a message syistem with the same features as claim 1 . 4^- 

Claim 1, as currently pending, is: 

A 1. A messaging system for delivering data in the form of portable message formats 
between message clients, 

B the messaging system based upon a publisli/subscribe mechanism or based upon a 
point-to-point protocol or based upon both a publish/subscribe mechanism and a point-to- 
point protocol. 

C the messaaing system comprising at least one transport protocol adapter, 

D whereby at least one transport protocol Is implemented before start-up of the message 
server and/or is implemented by a code at runtime of the message server 

E and said at least one transport protocol adapter 



comprises a logic to interface with said at least one transport protocol, 



F 



comprises another logic to specify a message delivery quality and 



G 



is pluggable for being started and/or stopped at runtime of the message server. 



wherein the utiderlined text has been added in a response to the office actions, and reference 
letters A-F denoting the different features are inserted for convenience. 
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Disclosure of white paper 

The White Paper discloses Softwired's concept for providing a framework on which 
publish/subscribe applications can be established. In contrast to fonner applications, the iBus 
system works transparently over a variety of underlying communication protocols and 
qualities of sei-yice. In order to allow this portability, protocol objects and a quality of service 
mechanism are introduced, as is summarized in section 5. 

The reduction to practice is implied in the downloadable softwaj:e mentioned on page 12, 
section 7. 

The individual features of the claim aie disclosed in the White Paper in the following 
manner. References to text in the White Paper are denoted by 

page number / (sub)secdon number (if the heading appears on the same page) / line number 
Feature A 

A messaging system for delivering data in the form of portable message formats t)etween 
rnessage clients rn-. 

The fact that a messaging system is the topic of the White Paper is obvious from the white 
paper as a whole, and stated explicitly in the first sentence: 

3/1/1-2 iBus 13 a pure HvsJ*^ publish/subscribe software bus allowing distributed components to 
exchange information via a variety of communication protocols and qualities of service. 

The poitability of message fomtats regardless of what channel and transport protocol is used 
is shown e.g. in: 

3/1/12-14 It allows iBus to deliver information not only using the Internet protocol family, but also 
by protocols such as infrared, paging, and satellite communication. 

9/5/6-7 Hence the application can be "poned*' from the IP network to tlie satellite network (and 
bacfc again) very easily. 

Feature B 

tfie messaging system based upon a publish/subscribe mechanism or based upon a point-to- 
point protocol or based upon both a publish/subscribe mechanism and a point-to-point protocol, 
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The different underlyitig protxx;ols are mentioned in various places, such as: 
The title of the white paper itself 1 

3/1/16-17 iBus supports tying a QoS lo each iBus communication channel, i.e. reliable point-to-poipt 
commanicatioD . reliable multicast, 

8/4/ J -3 In addition, synchronous requesi/veply style communication is provided. IB us thus offers 
thg complete fuaciionaiitv of a publish/subscribe software bus plus the main features found 
in ORBs. 

Feature C 

the messaging system comprising at least one transport protocol adapter, 
Section 5.1 (pages 9-10), with reference to Figure 2, describe the conversion of messages 
through a lineai' sequence of protocol conve3:ters. In Java, the converters are implemented as 
;v; software objects, called protocol objects. See in particular, with i:eference to the left half of 

Figure 2: 

IO/VI-6 A protocol stack represents cue QoS and consists of a liiieai- list of protocol objects. If an 
event object is published on a channel, it is passed to tlie protocol stack of t]ie channel. The 
event object passes through the topmost protocol object in the stack and is then passed 
along to the next protocol object in the stack until it reaches the boUomjnost object. The 
bottommost protocol object delivers the event to the net-work interface. 

This refei-s to the conversion of a message and its adaptation to the network channel over . 
which the message is transported. This means that the protocol objects are identical in 
function to the protocol adapters of tiie application, and that the lower protocol objects (such 
as IPMCAST) that adapt the message to the transporting channel are identical to the transport 
protocol adapters of the application. 

Similarly, on the receiving side, the riglit half of Figure 2 represents the receipt of a message 
through a protocol object (such as IPMCAST, but ananged for the receipt of messages), 
corresponding to another transport protocol adapter of the application. 

l(y-/6-7 The event is then received by the bottommost protocol object of the consumer application 
and is passed up the smck. 
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Protocol stacks can be modified by exchanging some or all protX)Col objects, which also 
implies the adaptation to different transport protocols by means of appropriate transport 
protocol adapters. 

1 1/5.2/1-2 The iBus QoS framework can be extended by implementing new protocol objects. These 
objects can then be put on top of tJie existing iBus stacks, or completely new stacks can be 
composed altogethci,. 

Feature D 

whereby at least. one transport protocol is implemented before start-up of the message server 
and/or is implemented by a code at runtime of ttie message server 

The White Paper shows this in: 

6/2.3/1-2 The system can be extended g^aceftally: you can start as many quote producers and 
consumers in whatever order you like. It is not necessary to start the consumers before the 
pi'oducers. 

n 

Ad example is given^ wherein for tapping into a channel a listener object receiving messages 
is created. Creating this object, retrieving the protocol adapter class by the JAVA import 
statement, and executing its software code necessarily implies that the transport protocol for 
recei ving messages is implemented at runtime 

5/2.2/1-3 An application tapping into the blue chips channel is written to tecave stock quotes. The 
consumer application is structured like the producer application. Its main diffeiience 
consists Ln creating a PublishListener object which is needed to receive the quotes 
transmitted on the channel. 



Feature E 

and said at least one transport protocol adapter 

comprises a logic to interface with said at least one transport protocol. 

This feature is disclosed in the same manner as feature C: The existence of a transport 
protocol adapter with the function of adapting a message to a specific transport protocol 
necessarily implies computer code or logic for implementing saidftuiction. 
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Feature F 

comprises another logic to specify a massage delivery quality and 
Ttie message delivery quality is an important aspect highlighted in die White Paper, e.g. in 
the entire section 5, starting on page 9. 

9/5/1-3 The capability to control qualities of services is one of iBus' distingiiislijng features. This 
is accomplished by cn^bcdding QoS strings into channel URLs. Altering the QoS of 
transniission channels thus only requires very minor modifications of the iBiiS appUcaUon. 

And in the introduction: 

3/1/12-14 A distinguishing featui'e of iBus is its Quality of Service (QoS) FramewofkAt 
allows iBus to deliver information not only using the Internet protocol family, but also 
by protocols such as infrared, paging, and satellite coinnnmication. 

Every communication channel can be associated with a quality of message: 

8/4/15 The ChaiuielURl. class is used to tie a QoS to a channel and will be examined next 

This is done when definiug a channel, according to the following syntax: 

9f-n iBus channel URLs obey die format 

"ibust-'t OoS":"! V/" [ address ](-: address parameter]"/" topic 

iBus URLs always start with the protocol descriptoi- " ibus : Tlie next part is an optional 

QoS string indicating the transport protocol and reliability guarantees of tlie channel. 

and further below two examples for specifying QoS as "reliable** or "unreliable" are given 

9/7)9-22 itius: CRYPT: alias (reliable) :/ //quotes /zrh/bluechips:Data is 
encryptedand sent via IP multicast. 

ibus : alias (unreliable) : / / /radiostations/RadioXYZ : Unreliable 
multicast is chosen to craasmit real-time audio in a best effort manner via UDP. 

Feature G 

is pluggable for being started and/or stopped at runtime of the message server. 
This is mentioned in 
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6/2.3/3-4 Plug&Play of components: producers and con&umei's can be relocated from one machine to 
another at run-time, without need to restan applications. 

which means that the producers cati be stopped (for relocating to another computer) whereas 

the message server does not have to be stopped. 

Corresponding mechanisms are implemented to handle such cases: 

7/3/10 ... whenever a component (producer or consumer) plugs into the channel and 
whenever a component disconnects, 
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